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Abrechnungs- und Kundenverwaltungssystem 



Beschreibung 

Die vorliegende Erfindung betriffl ein Abrechnungs- und Kundenverwaltungssy- 
stem. insbesondere fur Kommunikationsdienste, nach dem Oberbegriff des An- 
spruchs 1 . 



Abrechnungs- und Kundenverwaltungssysteme werden in alien Firmen eingesetzt, 
die Giiter oder Dienstleistungen anbieten, bei denen die Hohe des Verbrauchs der 
Guter bzw. die Lange der Nutzung der Dienstleistungen die wesentlichen Kriterien 
fur die Hohe des zu entrichtenden Preises durch den Endkonsumenten darstellen. 
Diese Firmen besitzen zudem meist eine sehr gro&e Anzahl an Kunden (vgl. 
Strom-, Gas- und Wasserversorgung, Telekommunikation), was einen enormen 
VenA/altungsaufwand nach sich zieht. Abrechnungs- und Kundenverwaltungssy- 
steme ermoglichen solchen Firmen zumeist eine einfache Verwaltung der enormen 
Menge an Kundendaten, berechnen nach entsprechenden Voreinstellungen die 
abzurechnenden Kosten und sind meist auch fur die Rechnungserstellung als sei- 
che zustandig. 



Bei den bekannten Abrechnungs- und Kundenvenwaltungssystemen wird eine zen- 
trale Datenbank eingesetzt die insbesondere zur Speicherung alter Anwendungs- 
daten dient. Diese ist jedoch meist als relationale Datenbank ausgebildet und stellt 
so zugleich den Hauptserver des Systems dar. Ober Clients, und insbesondere 
uber GUIs (Graphic User Interfaces), werden dem Anwender bestimmte Dienstlei- 
stungen des Kundenverwaltungs- und Abrechnungswesens ermoglicht. Dabei kon- 
nen zusatzliche Anwendungsserver zwischen die Clients und die Datenbank ge- 
schaltet sein. Jeder Client bzw. jeder Anwendungsserver ist mit der zentralen Da- 
tenbank verbunden, von der alle zur Anwendung notigen Daten abgefragt und ge- 
andert werden konnen. 
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Zum besseren Verstandnis wird im folgenden zunachst ein typisches Ausfuhrungs- 
beispiel eines vorbekannten Abrechnungs- und Kundenverwaltungssystems im Be- 
reich der Mobilfunk-Telekommunikation unter Bezugnahme auf Fig. 1 eriautert. An 
diesem Beispiel sollen die Ablaufe innerhalb eines derartlgen Systems und die 
Moglichkeiten, die das System liefem sollte. vereinfacht dargestellt werden. 

Das System 14 weist eine zentrale, relationale Datenbank 17 auf, die gleichzeitig 
den Hauptserver des Systems 14 bildet und mit einer Mehrzahl von Modulen 3 uber 
ein Netzwerk in Verbindung steht. Die Module 3 konnen jeweils entweder als Client 
Oder als Anwendungsserver mit angehangten Clients ausgebildet sein und bieten 
dem jeweiligen Nutzer uber GUIs Oder Programmierschnittstellen die Mdglichkeit, 
im voraus festgelegte Dienstleistungen aus dem Abrechnungs- oder Kundenverwal- 
tungsbereich in Anspruch zu nehmen. Die dazu notigen Datensatze sind in Tabel- 
len derzentralen Datenbank 1 7 gespeichert und werden von dort abgerufen. 

Aktive Mobil-Vermittlungsstellen (MSC: Mobile Switching Center) 32 ermittein und 
speichern Gesprachsdaten wie Ursprung, Ziel, Dauer und Dienst von Mobiltelefona- 
ten. Die Informationen werden in das Abrechnungs- und Kundenverwaltungssystem 
14 eingelesen und dort von geeigneten Abrechnungsmodulen 20 bearbeitet, welche 
die Gesprachsgebuhren berechnen (Rating). Die dazu erforderlichen Daten werden 
aus der zentralen Datenbank 17 abgerufen, und nach Ablauf des Abrechnungspro- 
zesses werden die neu ermittelten Daten wieder in der Datenbank 17 gespeichert. 
Diese Daten konnen wiederum von einem Rechnungserstellungsmodul 22 abgeru- 
fen werden, mit dessen Hilfe der Provider die Kundenrechnungen erstellen kann 
(Billing). Die Kundenverwaltung als solche (Customer Care) wird ebenfalls anhand 
mehrerer Module, die jeweils fur unterschiedliche Dienstleistungen venwendet wer- 
den, durchgefuhrt. Beispielsweise konnen uber ein Modul 24 Angaben uber freie 
Ressourcen an SIM-Karten-Verkaufer 34 weitergeleitet werden. Ebenso benotigt 
ein Provider Module 26 zur Abwicklung von Geldgeschaften mit Banken und Kre- 
ditkartenunternehmen 36 sowie Module 28 fiir die Ubermittlung von Daten an ein 
Teilnehmerregister (HLR: Home Location Register) 30 des Mobilfunknetzes, in dem 
Daten von Teilnehmern gespeichert werden. 
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Alle Module 3 sind direkt mit d r zentralen Dat nbank 17 verbunden. konnen un- 
tereinander jedoch nicht uber direkt Schnittstellen kommunizieren. Die Schnittstel- 
len zwischen den Modulen 3 sind ubiicherweise uberhaupt nicht explizit definiert. 
Statt dessen dient die zentrale Datenbank 17 als eine gro&e innplizite Schnittstelle 
zwischen alien verschiedenen Modulen 3, wodurch eine Vielzahl unnotiger interner 
Unterabhangigkelten verursacht wird. Die Schnittstelle wird demnach durch einen 
Satz an Datenbanktabellen dargestellt. In derartigen Systemen 14 wird die Daten- 
bank 17 aufierdem zumeist auch als Server dazu verwendet, die Geschaftslogik in 
den verschiedenen Modulen 3 zu konfigurleren, dient neben der Datenspeicherung 
zusatzlich als Schnittstelle zu externen Systemen und zur Kommunikation zwischen 
den Modulen 3. . 

Im Telekommunikationsbereich sind in den letzten Jahren durch die rasante Ent- 
wicklung neuer Technologien (Handy, WAP-Handy etc.) extrem groBe Veranderun- 
gen innerhalb kurzester Zeiten zu verzeichnen. Da zudem der Markt fur den freien 
Wettbewerb geoffnet ist, werden potentielle Kunden (Subscriber) von vielen Anbie- 
tern (Providern) immer starker umworben. Daher ist es filr einen Provider unum- 
ganglich, Veranderungen flexibel Rechnung zu tragen und schnell auf die Erfor- 
demisse des Marktes einzugehen. Im selben MaBe stetgen mit der Anzahl an 
Subscribern und der Vielfalt der technologischen Mogllchkeiten auch die Anforde- 
rungen an Abrechnungs- und Kundenverwaltungssysteme. 

Nachteilig an den vorbekannten Systemen ist, daS fur Modifikationen oder EnA^eite- 
rungen bei Anderungen im Anspruchsprofil des Systemnutzers immer der Code 
des entsprechenden Systems geandert werden mud. Dadurch entstehen sowohl 
erhohte Personalkosten als auch eine enorme Verzogerung bei der Anpassung des 
Systems an die Markterfordernisse. 

Dier vorliegenden Erfindung liegt daher die Aufgabe zugrunde, ein Abrechnungs- 
und Kundenverwaltungssystem, insbesondere fiir Kommunikationsdienste, zu 
schaffen, bei dem Anderungen oder En/veiterungen des Systems aufgrund gean- 
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derter Wunsche des Systemnutzers moglichst schnell mit moglichst geringem Pro- 
grammieraufwand durchgefuhrt warden konnen. 

Diese Aufgabe wird durch die Merkmale des Anspruchs 1 gelost. 

Dadurch, daR das System eine verteilte Komponentenarchitektur aufweist. in der 
entsprechend den angebotenen Dienstleistungen Konnponenten ausgebildet sind. 
die uber Schnlttstellen direkt nniteinander kommunizieren konnen. wird eine flexible 
Konfiguration der Geschaftslogik ermoglicht, so daB Kundenwunschen mit einem 
Minimum an Implementationsveranderungen nachgekommen werden kann. Zudem 
la&t sich das System auBerst flexibel und leicht an eine Erhdhung der Anzahl der 
zu verarbeitenden Daten anpassen. 

Vorteilhafterweise ist das System in mindestens zwei hierarchisch angeordnete 
Schichten (Layers) mit zunehmendem Abstraktionsgrad unterteilt. Jede Schicht 
isoliert die uber ihr liegende Schicht nach unten, so da& der dartiberliegenden 
Schicht Implementierungsdetails der darunterliegenden Schichten verborgen blei- 
ben. In der bevorzugten Ausfuhrungsform des erfindungsgemaBen Abrechnungs- 
und Kundenverwaltungssystems ist das System unterteilt in Basisschicht (Base 
Layer), allgemeine Schicht (Common Layer), technische Untersttitzungsschicht 
(Technical Services Layer), Anwendungsschicht (Application Layer) und Ge- 
schaftsschicht (Business Layer). 

Besonders vorteilhafl macht es sich bemerkbar, da(i das System in mindestens 
zwei hierarchisch angeordnete Ebenen (Tiers) entsprechend den technischen Auf- 
gaben unterteilt isL In verschiedenen logischen Ebenen konnen Prozesse gleich- 
zeitig und unabhangig voneinander ablaufen; zudem ist eine noch feinere Eintei- 
lung in physikalische Ebenen moglich. In der bevorzugten Ausfuhrungsform des 
erfindungsgemaBen Abrechnungs- und Kundenverwaltungssystems ist das System 
unterteilt in Prasentationsebene (Presentation Tier). Anwendungsebene 
(Application Tier), Meta-Anwendungsebene (Meta-Application Tier), Domainebene 
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(Domain tier), Persistenzebene (Persistence tier) und Datenbankebene (Database 
Tier). 

Uber die Meta-Anwendungs-Ebene (Meta-Application Tier) werden einer Anwen- 
dung innerhalb des Systems vorteilhaftenweise Mittel zur Verfugung gestellt. um 
sich selbst zu beschreiben. Dies eriaubt eine dynamische (d.h. zur Laufzeit durch- 
fiihrbare) Konfiguration des Verhaltens der einzelnen Komponenten. 

Besonders vorteilhaft weist das System ein Meta-Anwendungs-Dictionary (Meta- 
Application Dictionary) auf, wodurch der Programmieraufwand bei Anderungen auf 
Serverseite sehr gering gehalten werden kann. 

In einer vorteilhaften Weiterbildung weist das System Einrichtungen auf, die das 
Schnittstellenmodell des Servers auf der Cllentseite zur Verfugung stellen und 
damit die eingesetzte Kommunikationstechnologie vor einem Client-Entwickler ver- 
bergen. 

VorteilhaftenA/eise bietet das System definierte Schnittstellen und Mechanismen zur 
Anfrageverteilung an, so dad mehrere gleichartige Anwendungsserver dem System 
hinzugefiigt werden konnen, wodurch die mogliche Anzahl an zu verarbeitenden 
Daten mit geringem Aufwand nahezu beliebig erhoht werden kann, ohne die Verar- 
beitungsgeschwindigkeit zu beeintrachtigen. 

Das System bietet in vorteilhafter Welse die MOglichkeit. Komponenten auszutau- 
schen oder hinzuzufugen, so daB das System nicht veraltet und auf einfache Weise 
andere oder zusatzliche Dienstleistungen anbieten kann, ohne daR das komplette 
System ausgetauscht werden muR oder tiefgreifende Codeanderungen vorgenom- 
men werden mussen. Somit ist auch die Erstellung von Upgrades relativ kosten- 
gunstig und einfach. 
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Die Moglichkeit der Erweiterung von Klassen und/oder des Hinzufugens neuer 
Klassen liefert den Vorteil. eine Konnponente wahrend der Ausfuhrung unter Ver- 
wendung von Meta-Anwendungs-Einrichtungen verandern zu konnen. 

Vorteilhaftenweise wird die Arbeitsteilung innerhalb des Systenns dadurch gefordert. 
daK die Datenbank in eine Vielzahl von unabhangigen Datenbankabschnitten auf- 
geteilt ist und/oder mehrere voneinander getrennte Datenbanken existieren. die 
jeweils mit lediglich einer Komponente konnmunizieren. 

Vorteilhaft stellt das System Mechanismen zur Verfugung, die ein uber Komponen- 
ten verteiltes Transaktions- und Speichermanagement ermoglichen, wodurch die 
Robustheit und Zuverlassigkeit des Gesamtsystems sichergestellt wird. 

Weitere Einzelheiten, Merkmale und Vorteile der Erfindung ergeben sich aus der 
nachfolgenden Beschreibung unter Bezugnahme auf die Zeichnungen. Darin zeigt: 

Fig. 2 eine scliematische Darstellung des Aufbaus einer Ausfuhrungsform des 
erfmdungsgemaBen Abrechnungs- und Kundenvenvaltungssystems; 

Fig. 3 eine schematische Darstellung der systeminternen Architektur einer be- 
vorzugten Ausfuhrungsform des erfindungsgemaBen Abrechnungs- und 
Kundenverwaltungssystems mit der Unterteilung in Schichten mit zuneh- 
mendem Abstraktionsgrad und In Ebenen entsprechend den technischen 
Aufgaben; 

Fig. 4 eine schematische Darstellung der Kommunikationsmoglichkeiten zwi- 
schen Servern und Clients in der bevorzugten Ausfuhrungsform des er- 
findungsgemaBen Abrechnungs- und Kundenvenwaltungssystems von 
Fig. 3; und 
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Fig. 5 schematische Darstellungen des Aufbaus eines vorbekannten Systems, 
einer ersten und einer zweiten Ausfuhrungsform des erfindungsgematlen 
Abrechnungs- und Kundenverwaltungssystems. 

In Fig. 2 ist ein schematisches Modell einer ersten Ausfuhrungsform des erfin- 
dungsgemaUen Abrechnungs- und Kundenverwaltungssystems 1 dargestellt. In 
diesem System 1 dient eine Datenbank 7 lediglich zur permanenten Speicherung 
von Daten, die spater wieder abgerufen werden konnen. Die (ibrigen oben genann- 
ten Funktionen von Datenbanken 17, die in vorbekannten Systemen 14 eingesetzt 
werden, werden nun groBtenteils von der Anwendungslogik ubernommen. Entspre- 
chend der jeweils angebotenen Dienstleistungen im Bereich des Abrechnungs- 
bzw. Kundenvenvaltungswesens sind Komponenten 5 ausgebildet, die miteinander 
Liber gemeinsame Schnittstellen kommunizieren konnen und nicht die Datenbank 7 
als Schnittstelle venn/enden mussen. Damit wird ein schnellerer Informationsaus- 
tausch zwischen den einzelnen Anwendungen ermoglicht, und durch die Abtren- 
nung der Anwendungslogik aus der Datenbank 7 eine Struktur erreicht, die flexibel. 
erweiterbar und fur eine Verarbeitung von groBen Datenmengen geeignet ist. Ver- 
anderungen Oder Erweiterungen des Systems 1 konnen dabei ohne groRen Pro- 
grammieraufwand vorgenommen werden. Durch diese Struktur ist es m6glich, je- 
des Problem nur einmal zu losen, und die Losung auf einfache Weise fur alle Kom- 
ponenten 5 des Systems 1 verfugbar zu machen. Gleichzeitig ist fur nahezu jede 
implementierte Losung sichergestellt, dafi sie nicht nur ein bestimmtes festgelegtes 
Problem lost, sondern immer eine Kategorie von Problemen. 

Zur besseren Verdeutlichung des Begriffs "Komponente" in der Praxis soil im fol- 
genden an einem Beispiel aus dem Telekommunikationsbereich die Aufteilung der 
Dienstleistungen im Bereich Kundenverwaltung in einzelne Komponenten 5 darge- 
stellt werden. Eine Moglichkeit der Einteilung des Systems 1 liefert etwa folgende 
Komponenten 5: 

Risk Management, 
Fraud Management, 
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Trouble Ticket Management, 
Address Management, 
Accounts Receivable, 
Document Management, 
Task Management, 
Order Management. 
Product Management und 
Inventory Management. 

MIt Hilfe der Komponente "Risk Management" kann der Systemnutzer die Kredit- 
wurdigkeit von Kunden uberpriifen. Die Komponente "Fraud Management" wird zur 
Betrugsdetektion eingesetzt. Aufgedeckt werden dabei UnregelmaSigkeiten Oder 
Starke Abweichungen vom iiblichen Verhalten des Kunden, etwa wenn eine hohe 
Anzahl an Auslandsgesprachen be! einem Kunden festgestellt wird. der bisher nie 
ins Ausland telefoniert hat. In der Komponente "Trouble Ticket Management" wer- 
den Beschwerden von Kunden und Storungsmeldungen vom Netz selbst registriert 
und bearbeitet. Mit Hilfe der Komponente "Address Management" wird ein Adress- 
register venwaltet, das die Prufung der Plausibilitat einer Adresse eriaubt. Die Kom- 
ponente "Accounts Receivable" kann als eine Art Schuldbuchhaltungskomponente 
aufgefaBt werden. Mit ihrer Hilfe werden Zahlungseingange registriert. offene 
Rechnungen aufgedeckt und Konten ausgeglichen. Die Komponente "Document 
Management" steht zur Verwaltung von Kundendokumenten (Briefe. Faxe etc.) 
bereit. Durch die Dienstleistungen der Komponente "Task Management" werden 
nach Eingang von Auftragen die entsprechenden Arbeitsauftrage erteilt. Die Kom- 
ponente "Order Management" ist fur Auftragsbearbeitung und Kundenvenwal- 
tungsdienstleistungen zustandig. Mit Hilfe der Komponente "Product Management" 
kann der Endverbraucher liber die Verfugbarkeit von Produkten und uber Preisli- 
sten informiert werden. Die Komponente "Inventory Management" ist fur die Be- 
standsfuhrung zustandig, d.h. mit ihrer Hilfe ist eine Verwaltung der vergebenen 
und freien Telefonnummern, SIM-Karten oder anderer Gegenstande moglich. Jede 
der genannten Komponenten 5 erfullt eine relativ groBe Anzahl an Dienstleistun- 
gen. Wie bereits oben erwahnt konnen die Komponenten 5 uber direkte Schnittstel- 
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len Daten untereinander austauschen. Wenn also beispielsweise die Komponente 
"Accounts Receivable" speziell Kundendaten benotigt, greift sie nicht mehr auf 
Daten aus der Datenbank zuruck. sondern erhalt die erforderlichen Daten direkt 
von der Komponente "Order Management" oder entsprechenden anderen Kompo- 
nenten. 

Das Komponentenmodell fur ein Abrechnungs- und Kundenvenwaltungssystem 1 
setzt voraus, daft eine grundlegende Funktionalitat in einem zentralisierten Frame- 
work 10 verfugbar ist. Jede einzelne Komponente 5 ist von alien anderen Kompo- 
nenten unabhangig. Allerdings sind die Komponenten angewiesen auf einen Satz 
von Dienstleistungen, um korrekt arbeiten zu konnen. Diese benotigten Dienstlei- 
stungen konnen auch von Komponenten anderer Hersteller geliefert werden. Dann 
ist es moglich, diese in ein System mit den systemeigenen Komponenten zu inte- 
grieren. 

Das vorliegende System 1 ist jedoch nicht als rein dienstleistungsbasierendes Mo- 
dell ausgebildet, sondern weist auch etiiche Elemente eines eher objektorientierten 
Modells auf. Auf Einzelheiten wird spater noch genauer eingegangen. 

Es existieren zahlreiche Definitionen des Begriffs "Komponente" in der objektorien- 
tierten Programmierung. Diejenige. die den in der Praxis im vorliegenden Abrech- 
nungs- und Kundenverwaltungssystem 1 verwendeten Komponenten 5 am nach- 
sten kommt. lautet: 

"Eine Komponente ist eine Konstruktionseinheit mit vertraglict) spezifizierten 
Sclinittstellen und (wenn moglich) lediglicli expliziten Kontextabhangigkeiten. Eine 
Softwarekomponente kann unabliangig eingesetzt werden und ist Gegenstand fur 
eine zusammengesetzte Konstruktion mit Produkten Dritter " 

Die Hauptaspekte dieser Definition sind, dad eine Komponente 5 unabhangig von 
anderen Komponenten aufgestellt und eingesetzt werden kann, dali eine Kompo- 
nente 5 von anderen Anbietern verwendet werden kann, um Abrechnungs- oder 
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Kundenverwaltungssysteme zu bilden. und dali eine Komponente 5 lediglich 
Schnittstellen beinhaltet, d.h. keinen Zustand im ubiichen Sinne des Wortes auf- 
weist. obwohl eine Komponente 5 Eigenschaften haben kann und bestimmte ex- 
plizite AnsprCiche innerhalb eines Kontexts an ihren Einsatz stellt. 

Die Komponenten 5 im vorliegenden System 1 sind in der Regel relativ umfassend. 
Das folgt daraus, daB eine Komponente 5 unabhangig innerhalb eines bestimmten 
Kontexts eingesetzt werden kann und daher ausreichend abgeschlossen sein muB. 
Allerdings sind aucin Komponenten 5 mit lediglich einer Schnittstelle moglich. 

Komponentenschnittstellen sind in erster Linie dienstleistungsbasierend. Unter der 
Voraussetzung, dad eine Komponente 5 keinen Zustand besitzt. liefern die 
Schnittstellen, die von einer Komponenteninstanz geschaffen werden, Dienstlei- 
stungen und senden keine Information uber den Status der Komponente 5 zuruck. 
Die Anzahl der Dienstleistungen bzw. Schnittstellen, die von einer Komponente 5 
geliefert werden, muB der Zahl entsprechen, die nfitig ist, um den Satz an Verhal- 
ten vollstandig zu veroffentlichen, der innerhalb der Komponente 5 zusammenge- 
faBt ist. 

Wie bereits oben erwahnt. verwendet das vorliegende Komponentenmodell in er- 
ster Linie Dienstleistungen, insbesondere um den Einsatz von Komponenten 5 mit 
Komponenten anderer Hersteller zu ermoglichen. Andererseits venwendet das vor- 
liegende Abrechnungs- und Kundenvenwaltungssystems 1 zwischen den fur dieses 
System entwickeiten Komponenten 5 zusatzlich eine traditionellere, objektorientier- 
te Modellmdglichkeit. bei der Komponenten 5 ihre internen Klassen fur den Ge- 
brauch durch andere Komponenten verdffentlichen, was eher einer Peer-to-Peer- 
Architektur entspricht. 

Um Clients direkten Zugang zu den Objekten innerhalb einer Komponente 5 und 
deren Benutzung zu ermoglichen. wird eine zusatzliche Losung mit Peer-to-Peer- 
Objekten angeboten, so daR GUI-Entwickler auf einfache Weise mit modernen 
Werkzeugen arbeiten konnen, die auf einem model-view-artigen Pattern basieren. 
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Die Komponenten 5 existieren also als einzelne abgeschlossene Einheiten inner- 
halb eines Systems. Die technische Grundlage fur Ausfuhrung und Kommunikation 
wird durch ein Framework 10 geliefert. Das Framework 10 ist Teil des gesamten 
Systems 1, das durch die geschaftsspezifische Logik komplettiert wird. Details uber 
die Architektur des Systems 1 werden in der Beschreibung zu Fig. 3 eriautert. 

Komponenten 5 kommunizieren miteinander. wobel sie veroffentlichte Dienstlei- 
stungen verwenden, besitzen aber ebenso Anforderungen an den Kontext, d.h. das 
ganze Verhalten, auf das eine Komponente 5 angewiesen ist. und das nicht in der 
Komponente 5 selbst implementiert ist, kann von anderen Komponenten oder vom 
Framework stammen. Ein Hauptmerkmal des Frameworks betrifft die Abgeschlos- 
senheit, d.h. das Framework liefert den Behaiter fur die Ausftihrung einer Kompo- 
nente 5. AuBerdem eriaubt die Struktur des Komponentendesigns das einfache 
Packen von Anwendungselementen zum Zwecke der Abgeschlossenheit. 

Die Struktur der Komponentensoftware ist daher folgendermaSen: Geschaftsdo- 
mainklassen werden in Pakete gruppiert, wobei ein Paket eine relativ feine logische 
Domain darstellt. Diese Pakete werden in Komponenten 5 gruppiert, so daB Pakete 
in einer Komponente 5 Klassen enthalten, die sich bis zu einem gewissen Grad 
gegenseitig benutzen. wahrend Pakete in getrennten Komponenten 5 sich gegen- 
seitig so wenig wie moglich benutzen. Schliefllich werden Komponenten 5 zusam- 
men in Servern gruppiert. Diese Gruppierung kann freigestelit sein, wobei es gun- 
stig ist, wenn Komponenten 5, die oft miteinander kommunizieren. im selben Server 
zusammengefalit sind. Zur Verbindung mit fremden Frameworks ist es notig, so 
viele Abhangigketten als moglich zwischen der Ausfuhrungsumgebung und einer 
Komponente 5 zu entfernen. Daher benotigt jede Komponente 5 ihre eigene globa- 
le AbstractFactory-lnstanz; dies kann nicht pro Server geschehen. da es nicht ga- 
rantiert ist, da(J die Komponente 5 innerhalb dieses Servers laufen wird. 

Eines der Hauptkonzepte im Framework, die es zu einem Komponentenframework 
machen. ist die AbstractComponent-Klasse. Diese Klasse beinhaltet die Attribute 
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und das Verhalten, die alien Komponenten 5 gemeinsam sind. Spezifische Kompo- 
n nten 5 sind Unterklassen dieser Klasse. Da die Dienstleistungen, die von einer 
Komponente 5 geliefert werden, in Transaktionen involviert sind. und vielfache 
Komponentendienstleistungen in einer Transaktion venA/ickelt sein konnen. ist die 
AbstractConnponent-Klasse transaktional. 

Die Unterklassen der AbstractConnponent-Klasse, die eigentlichen Komponenten 5, 
enthalten atle Dienstleistungen, die fiir die Komponente 5 spezifisch sind. Ein wei- 
teres wesentliches Merkmal jeder Unterklasse ist eine Instanz einer Fassadenklas- 
se fur jede externe Komponente, mit der die Komponente 5 kommuniziert. 

Dienstleistungen an den Komponentengrenzen bzw. Dienstleistungen, die in ande- 
ren Komponenten implementiert sind. werden intern mittels Fassadenobjekten mo- 
delliert. Die Dienstleistungen in den Fassaden sind diejenigen, die die Komponente 
5 benotigt, um zu funktionieren. Beispielsweise weist Komponente "A" intern eine 
"B"-Fassadeninstanz und eine "C"-Fassadeninstanz auf, wenn sie Schnittstellen in 
den Komponenten "B" und "C" verwendet. Das Design und die Implementation der 
Komponente "A" konnen dann groRtenteils unabhangig von den Komponenten "B" 
und "C" ausgefuhrt werden. Wenn die Komponenten 5 eingesetzt werden, mCissen 
die Dienstleistungen in den Fassaden in geeignete Dienstleistungen in anderen 
Komponenten abgebildet werden. 

In einer bevorzugten Ausfuhrungsform des Abrechnungs- und Kundenverwaltungs- 
systems 1 sind diese Fassaden derart implementiert, dad das Mappen einer Fas- 
sadendienstleistung zu einer eigentlichen Komponentendienstleistung ohne Ande- 
rung des Codes ausgefuhrt werden kann. Aus diesem Grund existtert eine abstrak- 
te Klasse, die generelles Verhalten beinhaltet, die AbstractFacade-Klasse. Sowohl 
fur veroffentlichte Domainobjekte als auch fur Komponenten 5 unterstutzt das Fra- 
mework 10 Transaktionen zwischen Komponenten 5. Fur Dienstleistungspropaga- 
tion von Komponente zu Komponente wird implizite Propagation verwendet. Im 
Bereich Speicherverwaltung werden die Transaktionskontexte fur nicht transakti- 
onsbezogene Zwecke verwendet. 
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Zusammenfassend \aRi sich nochmals feststellen, daR die hier dargestellte bevor- 
zugte AusfQhrungsform des Abrechnungs- und Kundenverwaltungssystems 1 zum 
einen Dienstleistungen in Komponentenfassaden verwendet, wenn Dienstleistun- 
gen fur externa Komponenten geliefert werden nnussen. Ebenso veroffentlichen 
jedoch Komponenten 5 ihre internen Klassen fQr die Benutzung durch andere sy- 
steminterne Komponenten 5. 

In Fig. 3 ist die Einteilung des Systems 1 in hierarchisch angeordnete Schichten 
(Layers) mit zunehmendem Abstraktionsgrad und in Ebenen (Tiers) entsprechend 
den technischen Aufgaben unterteilt. Die Schichten und Ebenen in der Architektur 
des Systems 1 liefern eine zweidimensionale Matrix. Allerdings ist diese Untertei- 
lung in der Paketstruktur des Frameworks 10 nicht explizit reprasentiert. 

Jede Schicht (Layer) ist von den komplizierten Belangen der darunterliegenden 
Schichten isoliert. so dalS eine Kommunikation zwischen den Schichten nur mittels 
Benutzung von Standardschnittstellen implementiert wird. Dadurch wird ein hoher 
Grad an Flexibilitat und Unabhangigkeit gewahrleistet. 

In einer bevorzugten AusfQhrungsform ist das System 1 in fiinf Schichten unterteilt. 
Die unterste Basisschicht (Base Layer) 40 beinhaltet dabei Klassen, die grundle- 
gendes Verhalten liefern, wie Systemressourcen, Betriebssystem und hardware- 
spezifische Klassen. Die Schicht beinhaltet auch das Verhalten, das von benutzter 
Drittsoftware eriangt wird. In der bevorzugten AusfQhrungsform sind hierbei insbe- 
sondere die Grundlagen von CORBA, einer gemeinsamen Standardarchitektur fur 
Objektanforderungsvermittler, sowie von TopLink. einer objektsbezogenen Einrich- 
tung zum Abbilden. beinhaltet. Als Programmiersprache wird in dieser AusfQh- 
rungsform Java venA/endet. 

In der daruber angeordneten allgemeinen Schicht (Common Layer) 42 sind Ab- 
straktionen von Klassen der Basisschicht 40 sowie Klassen beinhaltet, die allge- 
meine Einrichtungen fQr alle Schichten und Ebenen liefern. Darin sind auch Ele- 
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mente fur das Mitprotokollieren (Logging) und fur die Fehlerbehandlung (Exception 
handling) beinhaltet. 

Dariiber angeordnet ist die technische Unterstiitzungsschicht (Technical Services 
Layer) 44. die Klassen beinhaltet, die software-technische Dienste anbietet. 

Die dariiber liegende Anwendungsschicht (Application Layer) 46 enthalt alle Klas- 
sen und das Verhalten fur eine dynamische Definition der Elemente einer Anwen- 
dung bzw. einer Konriponente 5 auf einem Meta-Level. Instanzen dieser Klassen 
werden bei Interaktionen mit einer echten Anwendung vervA^endet. Die Dienste der 
technischen Unterstiitzungsschicht 44 werden zu einer abstrakten Anwendung zu- 
sammengefaBt und Mechanisnnen zur Beschreibung der Elemente der Domaine- 
bene 58 auf einer Meta-Ebene eriaubt. Die Anwendungsschicht 46 beinhaltet die 
Klassen, die den hochsten Level an Abstraktion im System reprasentieren, bei- 
spielsweise die Factory, die verschiedene Dienstleistungen von den darunterlie- 
genden Schichten verwendet, wie etwa Transaktions- und Persistenzunterstutzung. 

Die Gesamtheit der Elemente von der Basisschicht 40 bis hin zu Teilen der An- 
wendungsschicht 46 kann auch als (technisches) Framework 10 bezeichnet wer- 
den. Erst durch die Geschaftsschicht (Business Layer) 50, die die spezifischen 
Klassen fur das Verhalten einer Anwendung und einer Komponente 5 enthalt. und 
in der die tatsachlichen dienstleistungsspezifischen Vorgange programmiert wer- 
den, wird das System 1 komplettiert. 

Durch die Isolation der einzelnen Schichten ist realisiert, da& beispielsweise die 
Tatigkeit eines Business-Logik-Entwicklers nicht von einer Anderung in einer darun- 
terliegenden Schicht (etwa einer Anderung des Betriebssystems) beeinfluflt wird. 

Das System 1 ist zudem in verschiedene Ebenen (Tiers) unterteilbar. Dabei ist zwi- 
schen der Aufteilung in logische und physikalische Ebenen zu unterscheiden. Die 
Aufteilung des Systems in zwei logische Ebenen (dicke Clients) bzw. drei logische 
Ebenen (diinne Clients) wird vorgenommen, da in verschiedenen logischen Ebenen 
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Verarbeitungsprozesse unabhangig voneinander und gleichzeitig ablaufen konnen. 
In der vorliegenden bevorzugten Ausfuhrungsform ist das System zudem in eine 
feinere Ebenenstruktur nach physikalischen Ebenen unterteilt. 

Die oberste und damit die dem Systemnutzer nachste Ebene ist dabei die Prasen- 
tationsebene (Presentation Tier) 52. Obwohl der Server eigentlich nicht mit der 
Prasentationsebene 52 in Verbindung steht, nnuB sein Framework 10 dennoch eini- 
ge Einrichtungen liefern, mit denen die Objekte der Prasentationsebene 52 kom- 
munizieren konnen, und zudem bestimmen, wie prasentationsspezifisches Verhal- 
ten behandelt werden muR. Die Elemente der Prasentation betreffen die Reprasen- 
tation von Informationen, die Navigation durch diese Informationen und deren Ma- 
nipulation. Das Framework 10 des Servers setzt die Venwendung einer objektorien- 
tierten Anwenderschnittstelle voraus und liefert entsprechende Einrichtungen. Die 
Elemente der Prasentationsebene 52 verwenden die beschreibende Information, 
die in Meta-Anwendungs-lnstanzen geliefert wird. um Aspekte zu definieren, wie 
Geschaftsobjekte und ihre Attribute betrachtet Oder ven/vendet werden sollen. Die- 
se Meta-Anwendungs-lnformation liefert eine Isolationsschicht zwischen den Pra- 
sentationsobjekten (Fenstern) und Anwendungs- oder Geschaflsobjekten. Eine 
zusatzliche Isolationsschicht kann durch Zugangspriviieg-Einrichtungen erreicht 
werden, die Serverelemente zeigen oder verstecken. 

Die Anwendungsebene (Application Tier) 54 beinhaltet Klassen und Schnittstellen, 
die die Anwendung reprasentieren, sowie Klassen, die auf Anwendung bezogenes 
Komponentenverhalten in Pakete packen. Enthalten sind eine Anzahl von Klassen. 
die fur die Interaktion mit einer Anwendung notwendig sind, sowie die fundamentale 
abstrakte Klasse fur Anwendungskontrollklassen und Anwendungsprozedklassen. 
Diese Klassen bilden die Hauptschnittstelle filr Clients innerhalb der Applikationen. 
Sie liefern die fundamentalen Mechanismen fur Kommunikation mit der Applikation. 
indem sie Instanzen von gewunschten Objekten erzeugen, und eriauben die Navi- 
gation zu diesen Objekten. 
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Zusammenfassend laSt sich deshalb vereinfacht sagen, dafi die Anwendungsebe- 
ne 54 die Klassen enthalt, die Geschaftsprozesse modellieren. welche zugrunde- 
liegende Geschaftsobjekte verwenden. Der Groliteil der individuellen Einstellungs- 
arbeit ist daher in dieser Ebene isoliert. 

Zudem enthalt die Anwendungsebene 54 die Fassadenobjekte, die die Hauptein- 
richtungen fiir die Kommunikation zwischen Komponenten 5 darstellen. 

Die Klassen in der Meta-Anwendungsebene (Meta-Application Tier) 56 liefern einer 
Anwendung Einrichtungen, um sich selbst zu beschreiben und zu andern. Die Me- 
ta-Anwendungsebene 56 besteht aus Klassen, die die Definition von Informationen 
bezuglich Aspekten von Anwendungsobjekten und Donnainobjekten eriauben. Die- 
se Klassen machen es moglich. Aspekte von Geschaftsobjekten dynamisch auf 
einem Meta-Level zu konfigurieren. Solche Aspekte beinhalten die Betitelung von 
Klassen, beinhalten weiter Fornnatniasken und Langen fiir Attribute, beinhalten In- 
formationen. ob bestimmte Attribute obligatorisch sind usw. 

Die Meta-Anwendungs-Einrichtungen liegen auf einem hoheren Level als die An- 
wendungen und liefern generelle Funktionalitat, die auf alle Anwendungen an- 
wendbar ist. 

Die Domainebene 58 weist die Geschaftsobjektklassen (business object classes) 
einer spezifischen Anwendungsdomain auf. In anderen Worten ist die Domainebe- 
ne 58 die Ebene, die als einzige Klassen beinhaltet, welche die Geschaftsdomain 
einer Anwendung modellieren. Daher beschrankt sich der Arbeitsbereich fur An- 
wendungsentwickler groBtenteils auf diese Ebene. 

Die Domainebene 58 besteht nahezu ausschlieHlich aus einer abstrakten Domain- 
klasse, von der alle Geschaftsobjekte ihr Verhalten vererbt bekommen. Zudem 
enthalt die Domainebene 58 Domainklassen, die jeweils Unterklassen der oben 
genannten abstrakten Klasse darstellen. Diese Klassen modellieren stabiles, nicht 
veranderliches Verhalten der z ntralen Klassen einer Problemdomain. Jedes un- 
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bestandige Verhalten, das eine Domainklasse betrifft, ist in Klassen zusammenge- 
faRt, die der Anwendungsebene 54 zugerechnet werden. aber durch die Domain- 
klassen benutzt werden. 

Die Persistenzebene (Persistence Tier) 60 ist die Ebene, die die Interaktionen zwi- 
schen Domainobjekten und einem persistenten Speicher zusammenfaRt. Somit 
beinhaltet sie das Verhalten. das Persistenz fiir Objekte liefert, namlich ihre Spei- 
cherung und das Abrufen. Die Ebene beinhaltet ebenso die Klasse, die die Verbin- 
dungen mit der Datenbank 7 verwaltet. Insgesamt stellt sie zum einen eine Abbil- 
dung des Klassenmodells der Domainebene 58 auf das Datennnodell der Daten- 
bank 7 dar und zum anderen unterstutzt sie Mechanisnnen zur transaktionsgesi- 
cherten Manipulation der Daten in der Datenbank 7. 

Die Funktionen der Datenbankebene 62 wurden bereits oben ausfuhrlich beschrie- 
ben. 

Die verschiedenen Variationsmoglichkeiten auf Server- bzw. Clientseite mit dem 
Ziel von Verdnderungen oder Erweiterungen des Systems 1 lassen sich am besten 
anhand des Schemas In Fig. 4 verdeutlichen. Aufbauend auf dem Framework 10 
sind Clientseite 70 und Serverseite 71 gesondert abgebildet. Auf der Serverseite 71 
sind die Geschaftsschichtobjekte 72, die Anwendungsschichtobjekte 74 und die 
Meta-Anwendungsschichtobjekte 76 anskizziert. Auf Clientseite 70 sind die erfor- 
derlichen Schnittstellen 66, insbesondere GUIs, ebenso enthalten wie speziell aus- 
gebildete JavaBeans 68. Die Pfeile skizzieren die jeweiligen Wechselwirkungsmog- 
lichkeiten zwischen Client und Server bzw. innerhalb des Clients. 

Durch die spezifisch ausgebildeten JavaBeans 68 konnen auf Clientseite 70 vorge- 
fertigte GUI-Einrichtungen erzeugt werden, so daB der Systemnutzer uber Benut- 
zerschnittstellen Einstellungen vornehmen kann, wodurch der Programmierauf- 
wand reduziert wird. Durch ihre Verwendung ist es moglich, das Schnittstellenmo- 
dell des Servers auf Clientseite 70 zur Verfugung zu stellen und damit die einge- 
setzte Kommunikationstechnologie vor einem Client-Entwickler zu verbergen. 
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Somit bekommt der Systemnutzer Schnittstellen zur Verfugung, an denen er sich 
anhangen kann. um seine Sonderwunsche zu implementieren. Dies geschieht an 
speziellen lokalisierten Stellen. so dad kein grundlegender Code geandert werden 
muR. 

Besonders hilfreich bei der DurchfQhrung dieses Vorhabens ist das Meta- 
Anwendungs-Dictionary. Dieses beinhaltet eine groBe Menge an Informationen 
uber eine Anwendung, ihre Klassen und die Attribute in den Klassen, weshalb das 
Meta-Anwendungs-Dictionary die dynamische Konfiguration von Anwendungsin- 
fomnationen und Verfahrensablaufen auf einem Meta-Level eriaubt. Das eigentliche 
Dictionary wird durch eine Instanz reprasentiert, die als Root des Dictionary's fun- 
giert und zusatzlich Infomiationen uber die Anwendung als solche beinhaltet. Des 
weiteren beinhaltet das Dictionary den Satz von Instanzen, die Meta-lnformationen 
fCir Klassen definieren. 

Durch das Meta-Anwendungs-Dictionary wird also eine Menge von Eigenschaften 
festgelegt. die fur jede Klasse im Server gelten. Somit ist eine Erweiterung bzw. 
Veranderung des Verhaltens des gesamten Systems 1 wahrend der Laufeeit mog- 
lich, ohne den bestehenden Code andern zu mussen. Diese Enweiterungen werden 
implementiert. indem sie von den Geschaftsklassen, die im Server aufgefuhrt wer- 
den, abgeleitet werden Oder als neue Klassen hinzugefugt werden. Die neuen 
Klassen werden in den Server konfiguriert, indem die Meta-Anwendungs- 
Einrichtungen des Servers verwendet werden. Diese Unterklassen konnen die 
meisten der existierenden Methoden uberschreiben und haben daher die Moglich- 
keit, die bestehende Funktionalitat zu verandern oder zu erweitern. 

Fig. 5 zeigt eine schematische Darstellung der Entwicklung von den vorbekannten 
Systemen 14 zu einer ersten und einer zweiten Ausftihrungsfonn des erfindungs- 
gemaUen Abrechnungs- und Kundenverwaltungssystems 1. Die in Fig. 5 vorge- 
nommene Einteilung der Systeme in drei logische Ebenen fur Prasentationslogik 
82. Anwendungslogik 80 und Datenbank 84 ist dabei lediglich als Hintergrund fur 
die bisher beschriebene Einteilung des erfindungsgemaBen Abrechnungs- und 
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Kundenverwaltungssystems 1 in physikalische Ebenen anzusehen. von denen wie 
erwahnt bevorzugterweise mehr als drei existieren konnen. 

In den vorbekannten Systemen 14 bildeten Prasentationslogik 82, Anwendungslo- 
gik 80 und Datenbank 17 jeweils einen groBen Block nnit entsprechenden Kommu- 
nikationsmoglichkeiten, die zu Fig. 1 bereits ausfuhrlich eriautert wurden. Im erfin- 
dungsgemafien System 1 ist es nun nicht nur moglich, die Anwendungslogik 80 
entsprechend den angebotenen Dienstleistungen zu separieren. vielmehr ist es 
auch denkbar, dafi die Datenbank 7 selbst in logisch getrennte Datenbankabschnit- 
te 12 aufgeteilt wird, anstelle einen groBen monolytischen Block zu bilden und/oder 
daS mehrere voneinander getrennte Datenbanken 12 existieren. Jeder Datenban- 
kabschnitt und/oder jede getrennte Datenbank 12 ist dann genau fiir eine Kompo- 
nente 5 zustandig, der sie Daten liefert und von der sie Daten abspeichert. 

Durch das vorliegende Abrechnungs- und Kundenverwaltungssystem 1 ist es mog- 
lich. weitere Anwendungsserver entsprechend bereits vorliegenden Servern zu re- 
produzleren und parallel zu diesen einzusetzen. Dadurch ist das Abrechnungs- und 
Kundenverwaltungssystem 1 auch fur Systemnutzer mit einigen Millionen abzu- 
rechnender Kunden und einer hohen Anzahl an Transaktionen geeignet. 

AuSerdem stellt das System 1 Mechanismen zur Verfugung, die ein uber die Kom- 
ponenten 5 verteiltes Transaktions- und Speichermanagement ermoglichen. 

Das oben dargestellte bevorzugte Modell des Abrechnungs- und Kundenverwal- 
tungssystems 1 ist lediglich als bevorzugte Ausftihrungsform aufzufassen, denkbar 
sind jedoch viele Abwandlungen von dieser speziellen Ausfuhrungsform. So ist bel- 
spielsweise die Anzahl der Schichten und Ebenen nicht exakt durch die in obigem 
Beispiel beschriebene Anzahl definiert, sondern kann beliebig nach oben oder un- 
ten variiert werden, solange die Unterteilung in mindestens zwei Schichten und 
mindestens zwei Ebenen beibehalten wird. Das System 1 laRt sich auch beliebig 
auf dunne oder dicke Clients anwenden. Die genaue Aufteilung in Komponenten 5, 
die zu Fig. 1 eriautert wurde, ist ebenso lediglich als Beispiel aufzufassen. Dem- 



4132 P 0794EP 



20 



nach konnen auch andere Dienstleistungen des Abrechnungs- und Kundenverwal- 
tungssektors zu einer entsprechenden Komponente 5 zusammengefaRt werden, 
solange die allgemeinen Kriterien fur eine Komponente 6 erfiillt werden. Auch die 
Verwendung von Java, CORBA und TopLink ist lediglich eine Frage des aktuellen 
Marktangebots; genauso ist es denkbar, andere Produkte mit ahnlichen Eigen- 
schaften fur die vorliegenden Zwecke einzusetzen. 

Besonders sei darauf hingewiesen, dad das Abrechnungs- und Kundenverwal- 
tungssystenn 1 nicht auf den Einsatz im Telekommunikationsbereich beschrankt ist, 
Vielmehr ist es durchaus moglich. das System 1 in der gesamten Verbraucherin- 
dustrie (Strom. Wasser, Gas, Internet etc.) einzusetzen bzw. Teile des Systems 1 
zur reinen Kundenverwaltung in Betrieben zu verwenden. 
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Pat ntanspruch 3 1- Mffll 



1. Abrechnungs- und Kundenverwaltungssystem (1), insbesondere filr Kom- 
munikationsdienste, mit 

mindestens einer Datenbank (7), in der Daten gespeichert und abgerufen 
werden konnen, und die bevorzugtenA/eise als Server ausgebildet ist, 

einer Mehrzahl von Clients, die mit der mindestens einen Datenbank (7) 
kommunizieren. und/oder mindestens einem Anwendungsserver mit zuge- 
horigen Clients, der mit der mindestens einen Datenbank (7) kommuniziert, 
und 

einem entsprechenden Framework (10). 

wobel dem Benutzer des Systems (1) entsprechende Dienstleistun- 
gen gem&Q> den jeweils gewunschten Abrechnungs- oder Kunden- 
verwaltungsvorgangen zur Nutzung offen stehen, 

dadurch gekennzelchnet, dall 

das System (1) eine vertellte Komponentenarchitektur aufweist, in der ent- 
sprechend den angebotenen Dienstleistungen Komponenten (5) ausgebildet 
sind, die uber Schnittstellen direkt miteinander kommunizieren konnen. 

2. Abrechnungs- und Kundenvenwaltungssystem (1) nach Anspruch 1, dadurch 
gekennzeichnet, da(X das System (1) in mindestens zwei hierarchisch ange- 
ordnete Schichten (Layers) zunehmenden Abstraktionsgrades unterteilt ist, 
wobei die jeweils nachstuntere die uber ihr liegende Schicht nach unten iso- 
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liert, so dalJ Implementierungsdetails der unterliegenden Schichten den da- 
rub rliegenden Schichten verborgen bleiben. 

3. Abrechnungs- und Kundenverwaltungssystenn (1) nach Anspruch 1 oder 2, 
dadurch gekennzeichnet. daB das System (1) in mindestens zwei hierar- 
chisch angeordnete Ebenen (Tiers) entsprechend den technischen Aufga- 
ben unterteilt 1st, wobei die Elemente alter Ebenen zusammen die Aufgaben 
von der Spelcherung bis zur Presentation der Daten vollstandig erfullen. 

4. Abrechnungs- und Kundenverwaltungssystenn (1) nach einem der Anspru- 
che 1 bis 3, dadurch gekennzeichnet, da(i das System (1) eine unterste Ba- 
sisschicht (Base Layer) (40) aufweist, die fundamentales Systemverhalten 
beinhaltet. 

5. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 4, dadurch gekennzeichnet, daB das System (1) eine uber der 
Basisschicht (40) angeordnete allgemeine Schicht (Common Layer) (42) 
aufweist, die Abstraktionen von Klassen der Basisschicht (40) und Klassen 
beinhaltet, die allgemeine Einrichtungen fur alle Schichten und Ebenen lie- 
fern. 

6. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 5, dadurch gekennzeichnet, daB das System (1) eine liber der all- 
gemeinen Schicht (42) angeordnete technische Unterstutzungsschicht 
(Technical Services Layer) (44) aufweist. die software-technische Dienste 
anbietet. 

7. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 6. dadurch gekennzeichnet, daB das System (1) eine uber der 
technischen Unterstutzungsschicht (44) angeordnete Anwendungsschicht 
(Application Layer) (46) aufweist, die die Dienste der technischen Unterstut- 
zungsschicht (44) zu einer abstrakten Anwendung zusammenfaBt sowie 
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Mechanismen zur Beschreibung der Elemente der Domainebene (58) auf 
einer Meta-Ebene erlaubt. 

8. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Ansprii- 
che 1 bis 7. dadurch gekennzeichnet, daR das System (1) eine uber der 
Anwendungsschicht (46) angeordnete Geschaftsschicht (Business Layer) 
(50) aufweist. die die domainspezifischen Klassen fur jede Komponente (5) 
beinhaltet. 

9. Abrechnungs- und KundenvenA/altungssystem (1) nach einem der Ansprii- 
che 1 bis 8. dadurch gekennzeichnet, dali das System (1) eine Prasentati- 
onsebene (Presentation Tier) (52) aufweist. die die Prasentation der Daten 
und Funktionen der Anwendung fur den Systemnutzer implementiert. 

10. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der AnsprQ- 
che 1 bis 9, dadurch gekennzeichnet, daB das System (1) eine Anwen- 
dungsebene (Application Tier) (54) aufweist, die Klassen sowie Schnittstel- 
len beinhaltet, die die Anwendung reprasentieren. 

11. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der AnsprQ- 
che 1 bis 10. dadurch gekennzeichnet, dalS das System (1) eine Meta- 
Anwendungsebene (Meta-Application Tier) (56) aufweist, in der Klassen 
beinhaltet sind, die einer Anwendung Mittel liefern, um sich selbst zu be- 
schreiben. 

12. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 11, dadurch gekennzeichnet, daB das System (1) eine Domaine- 
bene (Domain Tier) (58) aufweist, die die Geschaftsobjektklassen (business 
object classes) einer spezifischen Anwendungsdomain beinhalten. 

13. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der AnsprO- 
che 1 bis 12, dadurch gekennzeichnet, dad das System (1) eine Persi- 

4132P0794EP 



24 



stenzebene (Persistence Tier) (60) aufweist, die zum einen eine Abbildung 
des Klassenmodells der Domainebene (58) auf das Datenmodell der min- 
destens einen Datenbank (7) darstellt und zum anderen Mechanismen zur 
transaktionsgesicherten Manipulation der Daten in der mindestens einen 
Datenbank (7) unterstCitzt. 

14. Abrechnungs- und Kundenvenwaltungssystem (1) nach einem der Anspru- 
che 1 bis 13, dadurch gekennzeichnet, da& das Systenn (1) ein Meta- 
Anwendungs-Dictionary (Meta-Application Dictionary) aufweist, das Infor- 
mationen uber eine Konnponente (5), ihre Klassen und die Attribute in den 
Klassen beinhaltet und die dynamische Konfiguratlon von Anwendungsin- 
formationen und Verarbeitung auf einem Meta-Level eriaubt. 

15. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 14, dadurch gekennzeichnet. dad das System (1) Einrichtungen 
(68) aufweist. die das Schnittstellenmodell des Servers auf Clientseite (70) 
zur Verfugung stellen und damit die eingesetzte Kommunikationstechnologie 
vor einem Client-Entwickler verbergen. 

16. Abrechnungs- und Kundenvenwaltungssystem (1) nach einem der Anspru- 
che 1 bis 15, dadurch gekennzeichnet, dall das System (1) definierte 
Schnittstellen sowie Mechanismen zur Anfrageverteilung anbietet, so dad 
mehrere gleichartige Anwendungsserver dem System (1) hinzugefiigt wer- 
den konnen. 

17. Abrechnungs- und Kundenvenvaltungssystem (1) nach einem der Anspru- 
che 1 bis 16, dadurch gekennzeichnet, dal^ das System (1) die Moglichkeit 
bietet, Komponenten (5) auszutauschen oder hinzuzufugen. 

18. Abrechnungs- und KundenvenA/altungssystem (1) nach einem der Anspru- 
che 1 bis 17, dadurch gekennzeichnet, daB Klassen erweitert bzw. neue 
Klassen hinzugefiigt werden konnen, um eine Komponente wahrend der 
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Ausfiihrung unter Verwendung von Meta-Anwendungs-Einrichtungen zu 
verandern. 

19. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 18. dadurch gekennzeichnet. da& die Datenbank (7) als eine Viel- 
zahl unabhangiger Datenbankabschnitte (12) ausgebildet ist und/oder meh- 
rere unabhangige Datenbanken (12) existieren, wobei die unabhangigen 
Datenbankabschnitte und/oder unabhangigen Datenbanken (12) jeweils mit 
nur einer Komponente (5) konnmunizieren. 

20. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 19, dadurch gekennzeichnet. dad das System (1) Mechanismen 
zur Verfugung stellt. die ein uber Komponenten (5) verteiltes Transaktions- 
und Speichermanagement ermoglichen. 



3 
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Zusamm nfassung ^ ^' 2000 

Abrechnungs- und Kundenverwaltungssystem 

Die vorliegende Erfindung betrifft ein Abrechnungs- und KundenvenA/altungssystem 
(1), insbesondere fiir Kommunikationsdienste, mit mindestens einer Datenbank (7), 
in der Daten gespeichert und abgerufen werden konnen und die bevorzugterweise 
als Server ausgebildet ist. Das System (1) weist eine Mehrzahl von Clients auf. die 
mit der Datenbank (7) kommunizieren, und/oder mindestens einen Anwendungs- 
server mit zugehorigen Clients, der mit der Datenbank (7) kommuniziert, sowie ein 
entsprechendes Framework (10). Dem Benutzer des Systems (1) werden entspre- 
chende Dienstleistungen gemaB den jeweils gewunschten Abrechnungs- und Kun- 
denverwaltungsvorgangen zur Nutzung angeboten. Das System (1) ist dadurch 
gekennzeichnet, daB es eine verteitte Komponentenarchitektur aufweist, in der ent- 
sprechend den angebotenen Dienstleistungen Komponenten (5) ausgebildet sind, 
die uber Schnittstellen direkt miteinander kommunizieren konnen. 

Fig. 2 
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